Summary

• Replace HashMap with BTreeMap for DependencySet.dependencies and read_rollup_configs return type in kona's interop host
• Fixes non-deterministic JSON serialization that caused cannon VM state divergence between test helper and challenger processes

Root Cause

Rust's HashMap iteration order is randomized per-process via hash seeds. When kona-host serializes DependencySet and rollup configs as JSON preimages for the cannon VM, two separate kona-host processes (test helper vs challenger) can produce different byte sequences for the same logical data:

Process A: {"900200":{},"900201":{}}
Process B: {"900201":{},"900200":{}}

These different bytes get read into MIPS memory inside the cannon VM, producing different state hashes from that point forward. This causes the challenger to disagree with the test's claims, attack instead of defend, and step at a trace index that has no preimage data — so the preimage never gets uploaded to the oracle, and WaitForPreimageInOracle times out.

Evidence

• Binary diff of cannon VM snapshots at step 10M showed divergence at exactly the byte where chain ID order differs in serialized JSON (offset 6,827,040: dencies":{"90020 → one has 0":{},"900201" and the other has 1":{},"900200")
• Step 0 snapshots are identical (both from the same absolute prestate)
• The fix was verified with 68+ consecutive local test passes (still running, previously failed on the first run without the fix)

Test plan

• Reproduced locally — test failed on first run without fix
• Applied fix, rebuilt kona-host, ran 68+ consecutive passes (100-run verification still in progress)
• CI develop-fault-proofs workflow passes

Fixes #19892

🤖 Generated with Claude Code